STA - A Conceptual Model for System Evolution

A great deal of work on software maintenance focuses on source code analysis and manipulation. Code is viewed as a static entity that is – more or less – separated from the system at runtime. Although there are certainly important open questions in this field, the separation of code and runtime imposes itself an obstacle for the evolution of continuously functioning systems. The goal of the work presented in this paper is to blur the separation between statics and dynamics of a software system on a conceptual level. To achieve this, we propose a system model that combines space, time and level of abstraction and a conceptual framework for incremental evolution of systems during execution. Based on this continuously functioning systems can be maintained in a highly flexible and conceptually sound way. 1. Extending Software Evolution to Systems Software evolution often follows the pattern: save, shutdown, modify, restart, restore. Despite of its simple structure, this maintenance cycle already raises numerous nontrivial questions, such as how can the system state be captured at an arbitrary point in time, and how can quality be reassured after modification. Independent from these questions, this static view of evolution assumes that it is possible – and reasonable! – to shut the system to be maintained down. In cases of continuous operation, such as large-scale mission-critical databases or central components within a network this assumption does not hold. Thus, dynamic evolution, i. e. adapting the system during its runtime without (or hardly any) disruption of its operation is strongly more favorable. ∗Part of this work was sponsored by the German Federal Ministry for Education and Research (BMBF) as part of the project ViSEK (Virtual Software Engineering Competence Center). 1.1. The Relationship Between Source Code and Execution We argue, that the main obstacle for more flexible maintenance techniques is the separation of source code1 and system in execution2. Code is viewed as a static entity with few conceptually sound links with the system. As a consequence, the important link between the source level program and the system is lost. This has several negative consequences. E. g. there is no evolvable representation of the system if the code is modified while the system is executing and individual modification of two instances a and b of class c, specified by a single piece of code, requires versioning. Indeed, most contemporary work on system design and modeling such as the UML concentrates on static properties of a software system although the separation between static code and dynamic execution is artificial. It was introduced with the compilation and linking techniques of the early 1960’s. Interpreters, for example, do not impose a barrier between code and execution. The source code can be freely modified while the system is executing and changes take immediate effect. Obviously, conventional interpreters can as well not be considered a reasonable choice for system evolution. First, their performance is unsatisfactory and second, being able to perform arbitrary modifications of the source code at any time without control on the semantic effects of the changes eventually produces chaos. Our approach to eliminate the boundary between code and system is based on the vision that each component3 could be transformed into a piece of code and vice versa. The only difference between code and system is the level of abstraction. Whereas code is a high-level and humanreadable representation of a component, values in registers and in main memory provide an identical low-level repre1“code” further-on abbreviates source code 2“system” further-on abbreviates system in execution 3“component” refers to any conceptual entity that is part of the execution of the system; i. e. object instances, data items, functions, etc. sentation. Thus, code is regarded as the description of state and behavior of dynamically executing components and every component at runtime is described by its own code. Evolution always affects code and system simultaneously.